새줄 문자

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
- 2.1. 초기 타자기와 텔레프린터
- 2.2. 컴퓨터 시스템의 발전
3. 표현
4. 프로그래밍 언어에서의 처리
5. 호환성 문제 및 해결 방안
- 5.1. 문제점
- 5.2. 해결 방안
6. 한국 IT 환경과 개행 문자
참조

1. 개요

새 줄 문자(Newline)는 텍스트에서 줄 바꿈을 나타내는 데 사용되는 제어 문자 또는 문자 시퀀스를 의미한다. 19세기 모스 부호 통신에서 시작되어 텔레프린터 시대를 거치며 ASCII 표준에 정의되었으며, 운영 체제와 프로그래밍 언어에 따라 다양한 방식으로 표현된다. 주요 표현 방식으로는 유닉스 계열 시스템에서 사용되는 LF (Line Feed), 윈도우 시스템에서 사용되는 CR+LF (Carriage Return + Line Feed), 그리고 구형 맥 OS에서 사용되었던 CR 등이 있다. 이러한 차이로 인해 시스템 간 텍스트 파일 교환 시 호환성 문제가 발생할 수 있으며, 텍스트 편집기나 변환 도구를 사용하여 해결할 수 있다.

2. 역사

개행 문자의 기원은 타자기와 텔레프린터의 작동 방식에 있으며, 모스 부호 통신에서 사용되던 '새 줄' 또는 '새 섹션'을 나타내는 기호에서 유래했다.

초기 타자기와 텔레프린터에서는 캐리지 리턴(CR)과 라인 피드(LF)라는 두 가지 동작을 사용하여 줄바꿈을 표현했다. 컴퓨터 시스템에서도 이러한 방식을 차용하여 CR+LF, LF 등의 조합을 사용하게 되었다.

각 운영체제별 개행 문자는 다음과 같다.

운영체제별 개행 문자
운영체제	문자 인코딩	약어	16진수 값	10진수 값	이스케이프 시퀀스
Multics, POSIX 표준 지향 시스템(Unix 및 유닉스 계열 시스템 (Linux, macOS, *BSD, AIX, Xenix 등), QNX 4+, BeOS, Amiga, RISC OS 등)	ASCII	LF	0A	10	\n
Windows, MS-DOS 호환, Atari TOS, DEC TOPS-10, RT-11, CP/M, MP/M, OS/2, Symbian OS, Palm OS, Amstrad CPC 및 기타 초기 비유닉스 및 비IBM 운영 체제		CR LF	0D 0A	13 10	\r\n
Commodore 64, Commodore 128, Acorn BBC, ZX Spectrum, TRS-80, Apple II, Oberon, 클래식 Mac OS, HP Series 80, MIT Lisp 머신, 및 OS-9		CR	0D	13	\r
Acorn BBC^[6] 및 RISC OS 스풀 텍스트 출력^[7]		LF CR	0A 0D	10 13	\n\r
QNX 사전 POSIX 구현 (버전 < 4)		RS	1E	30	\036
Atari 8비트 컴퓨터	ATASCII	EOL	9B	155
IBM 메인프레임 시스템, z/OS (OS/390) 및 IBM i (OS/400) 포함	EBCDIC	NL	15	21	\025
ZX80 및 ZX81 (Sinclair Research Ltd의 가정용 컴퓨터)	ZX80/ZX81 고유 인코딩		76	118

2. 1. 초기 타자기와 텔레프린터

타자기에서는 줄바꿈을 위해 캐리지 리턴(CR)과 라인 피드(LF)라는 두 가지 동작을 사용했다. 캐리지 리턴은 종이를 왼쪽 끝으로 이동시키는 동작이고, 라인 피드는 종이를 한 줄 위로 올리는 동작이다.

초기 텔레프린터는 이러한 타자기의 방식을 따라 CR+LF 조합을 사용하여 줄바꿈을 표현했다. 텔레프린터의 프린터가 다음 줄의 처음부터 인쇄하려면 두 글자를 인쇄하는 시간이 필요했기 때문이다. 즉, 캐리지가 오른쪽 끝에서 왼쪽 끝으로 이동하는 시간 동안 CR 코드를 먼저 전송하고, 종이를 한 줄 올리는 LF 코드를 이어서 전송하는 방식이었다.^[2] 때로는 캐리지가 이동하는 시간이 더 필요하여 CR이나 NUL(아무것도 하지 않는 코드)을 추가하기도 했다.^[2]

모스 부호 통신사들은 텔레프린터와 텔레타이프 기계가 등장하기 훨씬 전인 1800년대 중반에 이미 공식적인 서면 텍스트 메시지에서 공백 텍스트 서식을 표현하기 위해 모스 부호 기호를 사용했다. 특히, '''''' (텍스트 중단) 기호는 모스 부호에서 새 줄 또는 새 섹션을 나타내는 데 사용되었다.

2. 2. 컴퓨터 시스템의 발전

ISO와 ANSI의 전신인 ASA는 ASCII를 동시에 개발했다. 1963년부터 1968년까지 ISO 초안은 CR+LF와 LF를 새줄 문자로 정했지만, ASA의 초안은 CR+LF만 지원했다.^[2] CR+LF는 텔레타이프 ASR33을 콘솔 장치로 사용한 초기 컴퓨터 시스템에서 널리 쓰였다.^[2]

텔레프린터가 다음 줄의 처음부터 인쇄하기 위해서는 두 글자를 인쇄하는 시간이 필요했다. 프린터에서 좌우로 움직이는 장치인 캐리지가 오른쪽 끝에서 왼쪽 끝으로 이동하는 시간이 두 글자 인쇄하는 만큼 걸렸기 때문이다. 그래서 텔레타이프를 쓰던 시절에는 CR+LF 두 코드를 새줄 문자로 썼다. 캐리지 리턴(CR)이 먼저 전송되고, 종이를 한 줄 옮기는 라인 피드(LF)가 이어서 전송되었다.^[2]

컴퓨터가 막 탄생하던 시절에는 디스크와 메모리가 비쌌기 때문에 1964년에 나온 운영 체제 멀틱스는 새줄 문자를 LF 하나로 통일했다. 유닉스도 멀틱스의 새줄 문자 관례를 이어받았고, 리눅스도 이 방식을 쓰고 있다.

1981년에 등장한 MS-DOS는 CP/M의 CR+LF 방식을 따랐다. CP/M은 시리얼 라인으로 터미널을 연결했기 때문에 화면 전환 속도가 느렸다. 느린 터미널에서 줄바꿈이 있을 때 스크롤 하는 시간과 보조를 맞추기 위해 CR+LF 방식을 쓰는 것이 자연스러웠다. 윈도우도 이 관례를 따르고 있다.

3. 표현

시스템과 운영 체제에 따라 줄바꿈을 표현하는 방법은 여러 가지가 있다. 윈도우는 ASCII의 CR+LF로 새줄을 나타내고, 유닉스는 LF로 새줄을 나타낸다. 맥 OS는 새줄 문자로 버전 9까지 CR을 썼지만, 버전 10부터는 LF를 쓰고 있다. 이밖에도 다른 코드를 사용하는 시스템도 있으며, 특정 코드를 사용하지 않고 레코드 하나에 한 줄씩 저장하거나 줄의 길이를 고정시켜서 줄바꿈을 표현하는 시스템도 있다.

1800년대 중반, 텔레프린터와 텔레타이프 기계가 등장하기 훨씬 전, 모스 부호 통신사 또는 전신기사들은 공식적인 서면 텍스트 메시지에서 공백 텍스트 서식을 인코딩하기 위해 모스 부호 기호를 발명하여 사용했다. 특히, 문자 "B"와 "T"를 일반적인 문자 간 간격 없이 연결하여 표현하는 모스 부호 기호 ''''''는 모스 부호에서 공식적인 텍스트 메시지의 ''새 줄'' 또는 ''새 섹션''을 나타내는 데 사용되었다.

이후, 현대 텔레프린터 시대에 표준화된 문자 집합 제어 코드가 개발되어 공백 텍스트 서식을 지원했다. ASCII는 국제 표준화 기구(ISO)와 미국 표준 협회(ASA, 미국 국립 표준 협회(ANSI)의 전신)에서 동시에 개발되었으며, 1963년부터 1968년까지 ISO 초안 표준은 LF 또는 CR+LF를 새 줄로 사용하는 것을 지원했으며, ASA 초안은 CR+LF만 지원했다.

CR+LF 시퀀스는 콘솔 장치로 Teletype 기계(일반적으로 Teletype Model 33 ASR)를 채택한 많은 초기 컴퓨터 시스템에서 일반적으로 사용되었다. 이 시퀀스는 해당 프린터를 새 줄의 시작 위치로 배치하는 데 필요했기 때문이다. 새 줄을 두 기능(CR, LF)으로 분리하면, 프린트 헤드가 다음 문자를 인쇄할 시간에 맞춰 오른쪽 끝에서 다음 줄의 시작 부분으로 돌아갈 수 없다는 사실이 숨겨졌다. CR 다음에 인쇄된 문자는 종종 프린트 헤드가 여전히 캐리지를 첫 번째 위치로 이동하는 동안 페이지 중간에 얼룩으로 인쇄되었다. "해결책은 새 줄을 두 문자로 만드는 것이었다. CR은 캐리지를 1열로 이동시키고, LF는 용지를 위로 이동시켰다."^[2] 프린트 헤드가 왼쪽 여백으로 이동할 시간을 주기 위해 불필요한 CR 또는 NUL과 같은 추가 출력 패딩 문자를 전송해야 하는 경우가 많았다. 많은 초기 비디오 디스플레이도 디스플레이를 스크롤하는 데 여러 문자 시간이 필요했다.

이러한 시스템에서 응용 프로그램은 Teletype 기계와 직접 통신하여 해당 규칙을 따라야 했다. 응용 프로그램에서 이러한 하드웨어 세부 정보를 숨기는 장치 드라이버 개념이 아직 잘 개발되지 않았기 때문이다. 따라서 텍스트는 Teletype 기계의 요구 사항을 충족하도록 구성되었다. DEC의 대부분의 미니 컴퓨터 시스템은 이 규칙을 사용했다. CP/M 또한 미니 컴퓨터가 사용했던 것과 동일한 터미널에서 인쇄하기 위해 사용했다. 거기에서 MS-DOS (1981)는 호환성을 위해 CP/M의 CR+LF를 채택했으며, 이 규칙은 Microsoft의 이후 Windows 운영 체제에 의해 상속되었다.

Multics 운영 체제는 1964년에 개발을 시작했으며 LF만 새 줄로 사용했다. Multics는 이 문자를 프린터가 필요로 하는 시퀀스(추가 출력 패딩 문자 포함)로 변환하기 위해 장치 드라이버를 사용했으며, 단일 바이트가 프로그래밍에 더 편리했다. CR은 굵게, 밑줄 및 취소선 효과를 만들기 위해 한 줄을 다른 줄로 덮어쓰는 유용한 기능을 제공했기 때문에 사용되지 않았다. LF만 줄 종결자로 사용하는 것이 이미 최종 ISO/IEC 646 표준 초안에 포함되었다는 점도 중요하다. 유닉스는 Multics 방식을 따랐고, 이후 유닉스 계열 시스템이 유닉스를 따랐다. 이로 인해 Windows와 유닉스 계열 운영 체제 간에 충돌이 발생하여 한 운영 체제에서 작성된 파일이 다른 운영 체제에서 제대로 서식이 지정되거나 해석되지 않을 수 있다(예: 메모장과 같은 Windows 텍스트 편집기에서 작성된 UNIX 셸 스크립트^[3]^[4]).

캐리지 리턴(CR)과 라인 피드(LF)는 밀접하게 연관되어 있으며, 개별적으로 또는 함께 고려될 수 있다. 타자기와 프린터에서 새 줄을 만들려면 "아래"와 "가로" 두 축의 움직임이 필요하다. 기계 디자인은 이를 개별적으로 고려해야 하지만, 소프트웨어에서는 하나로 결합할 수 있다. 그래서 문자 인코딩에서 줄 바꿈이 CR+LF 형태로 정의되기도 한다.

일부 문자 집합은 별도의 줄 바꿈 문자 코드를 제공한다. 예를 들어, EBCDIC는 CR 및 LF 코드 외에도 NL 문자 코드를 제공한다. 유니코드는 ASCII CR 및 LF 제어 코드 외에도 "다음 줄"(NEL) 제어 코드와 "줄 구분 기호" 및 "단락 구분 기호" 마커에 대한 제어 코드를 제공한다. 유니코드에는 줄 바꿈, 캐리지 리턴 및 기타 C0 제어 코드를 시각적으로 나타내는 인쇄 가능한 문자가 제어 그림 블록에 포함되어 있다.

단어 줄 바꿈 기능을 구현하는 소프트웨어를 사용하여 주로 사람이 읽도록 의도된 텍스트에서 새 줄 문자는 다음 단어가 같은 줄에 맞는지 여부에 관계없이 줄 바꿈이 필요한 경우(예: 문단 사이)에만 저장하면 된다. 워드 프로세서와 대부분의 텍스트 편집기에서 새 줄 문자는 ''문단 구분''으로 사용되며 "하드 캐리지 리턴"이라고 불린다. 이는 단어 줄 바꿈을 구현하기 위해 동적으로 생성되고 변경 가능한 "소프트 캐리지 리턴"과 대조된다. 많은 응용 프로그램에서 단일 문단 내에서 줄 바꿈을 강제하기 위해 "수동 줄 바꿈"이라는 별도의 제어 문자가 존재한다. 하드 캐리지 리턴에 대한 제어 문자의 글리프는 파일크로우 (¶)이고, 수동 줄 바꿈의 경우 캐리지 리턴 화살표(↵)이다.

개행 문자('''광의''')는 다음 두 종류가 있으며, 시스템(소프트웨어)에 따라 한쪽 또는 양쪽이 사용된다.

캐리지 리턴(carriage return^영어, '''CR''', 복귀)
라인 피드(line feed^영어, '''LF''', '''협의'''의 개행) 또는 뉴라인(newline^영어, line break^영어 또는 end-of-line^영어, '''EOL''')

이러한 용어는 타자기에서 유래되었다. 타자기에서는 인쇄 장치가 고정되어 있고, 종이가 상하좌우로 이동하여 문자 간격 조절 및 줄 바꿈이 이루어진다. 좌측 가로쓰기에서 "캐리지 리턴"은 종이를 고정하고 이동하는 장치(캐리지)를 원래 위치로 되돌리는 것을 의미한다. "라인 피드"는 종이를 필요한 줄만큼 위로 올리는 것을 의미한다.

컴퓨터에서는 같은 문자 코드를 사용하더라도 개행 코드가 다를 수 있으므로, 다른 시스템 간의 데이터 교환 시에는 개행이 정확하게 반영되지 않을 수 있다.

3. 1. ASCII 기반 시스템

ASCII 시스템에서는 새줄 문자로 라인 피드(line feed, LF, '\n', 0x0A), 캐리지 리턴(carriage return, CR, '\r', 0x0D)이 주로 사용된다.^[2] 라인 피드는 프린터에서 종이가 한 줄씩 인쇄되며 나오는 것을 뜻한다. 캐리지 리턴은 프린터에서 실제 인쇄를 수행하는 장치가 한 줄의 끝에서 시작 위치로 돌아가는 것을 뜻한다. 드물게 RS(record separator, 0x1E)를 새줄 문자로 쓰는 시스템도 있었다.

ASCII의 새줄 문자
LF	멀틱스, 유닉스, 리눅스, 제닉스, AIX, OS X, FreeBSD
CR+LF	DEC TOPS-10, RT-11, CP/M, MP/M, 도스, OS/2, 윈도우, 심비안 OS, 팜 OS
CR	코모도어 8비트 머신, TRS-80, 애플 II, 맥 OS (버전 9 이하), OS-9
RS	POSIX 이전의 QNX

HTTP, SMTP, FTP, IRC 등 인터넷 프로토콜 대부분은 ASCII의 CR+LF를 새줄 문자로 사용하도록 규정하고 있다. 그러나 홀로 쓰인 LF도 지원하도록 권장하고 있다.

대부분의 시스템에서 줄 바꿈 코드는 하나 또는 연속된 두 개의 특수 문자로 표현된다. ASCII 문자 코드 기반 시스템에서는 CR (캐리지 리턴, 0D_(16진)), LF (라인 피드, 0A_(16진)), 또는 CR+LF로 나타낸다.

LF: UNIX 및 유닉스 계열 시스템. 리눅스, 크롬 OS, AIX, 제닉스, macOS, BeOS, Amiga, RISC OS 등.
CR+LF: CP/M, MP/M, MS-DOS, OS/2, 마이크로소프트 윈도우.
CR: 코모도어 시스템, Apple II 제품군, Mac OS (버전 9까지), OS-9.

3. 2. 유니코드

유니코드 표준은 여러 글자를 줄바꿈 문자로 정의했다. 유니코드를 지원하는 프로그램은 이것들을 한 줄의 끝으로 인식해야 한다.^[9]

유니코드의 새줄 문자
LF	라인 피드(Line Feed), U+000A
FF	폼 피드(Form Feed), U+000C
CR	캐리지 리턴(Carriage Return), U+000D
CR+LF	연속된 CR과 LF
NEL	다음 줄(Next Line), U+0085
LS	줄 구분자(Line Separator), U+2028
PS	문단 구분자(Paragraph Separator), U+2029

캐리지 리턴(CR)과 라인 피드(LF)는 밀접하게 연관되어 있으며, 개별적으로 또는 함께 줄바꿈으로 사용될 수 있다. 타자기와 프린터에서 새 줄을 만들려면 "아래"와 "가로" 두 방향으로 움직여야 한다. 기계 디자인에서는 이를 분리했지만, 소프트웨어에서는 하나로 합쳐 처리할 수 있다. 그래서 문자 인코딩에서 CR+LF 형태로 줄바꿈을 정의하기도 한다.

유니코드는 기존 인코딩과의 호환성을 위해 다양한 줄바꿈 문자를 제공한다. 예를 들어, EBCDIC의 NL (New Line) 문자는 유니코드의 NEL (Next Line, U+0085)에 대응된다. 이러한 방식은 텍스트 파일을 유니코드로 변환하고 다시 원래 인코딩으로 되돌릴 때 정보 손실 없이 처리할 수 있도록 해준다.( 왕복 무결성)

하지만 NEL, LS, PS (U+0085보다 큰 코드)와 같은 줄바꿈 코드는 실제로 자주 사용되지는 않는다. 이들은 UTF-8에서 여러 바이트로 표현되고, NEL 코드는 Windows-1252에서 줄임표(…) 문자로 사용되기도 한다.

몇몇 응용 프로그램의 사례는 다음과 같다.

ECMAScript는 LS와 PS는 줄바꿈으로 허용하지만,^[13] NEL (U+0085)은 공백으로 간주한다.^[14]
JSON^[15]은 문자열 내에서 LS 및 PS 문자를 허용하는 반면, ES2019 이전의 ECMAScript^[16]^[17]는 이를 줄바꿈으로 취급하여 불법적인 구문으로 처리했다.^[18]
YAML^[19]은 JSON과의 호환성을 위해 버전 1.2부터 더 이상 줄바꿈으로 인식하지 않는다.
Windows 메모장은 NEL, LS, PS를 줄바꿈으로 처리하지 않는다.
gedit는 NEL이 아닌 LS와 PS를 줄바꿈으로 취급한다.

유니코드 특수 문자인 U+2424 (NEWLINE의 기호, ␤), U+23CE (RETURN 기호, ⏎), U+240D (캐리지 리턴의 기호, ␍) 및 U+240A (줄 바꿈의 기호, ␊)는 사용자에게 보이는 문자를 표시하기 위한 글리프이며, 줄 바꿈 자체로 인식되지 않는다.

3. 3. EBCDIC

IBM의 메인프레임 시스템에서는 주로 NEL (Next Line^[8])을 새줄 문자로 사용한다. EBCDIC에는 CR과 LF라고 불리는 제어 문자도 있지만, 이들은 ASCII에서의 CR과 LF와는 값이 다르다. NEL에 대해 다른 값을 할당한 EBCDIC 변종도 존재한다. z/OS (OS/390) 및 IBM i (OS/400)를 포함한 EBCDIC 시스템은 라인 피드 및 캐리지 리턴의 기능을 결합하는 문자로 NEL (New Line)을 사용하며, 해당 유니코드 문자는 NEL (Next Line)이라고 한다. 그러나 해당 운영 체제는 레코드 지향 파일 시스템을 사용하며, 텍스트 파일을 줄당 하나의 레코드로 저장한다. 대부분의 파일 형식에서는 줄 종결자가 실제로 저장되지 않는다.

3. 4. 기타 코드 및 레코드 방식

CDC 6000 시리즈의 운영 체제는 60비트짜리 단어 끝에 6비트짜리 글자 2개 이상이 0으로 채워진 상태를 새줄 문자로 정의했다. 일부 설정에서는 0 대신 콜론을 채우는 문자로 사용하도록 변경할 수 있었다.^[8] 싱클레어 리서치의 가정용 컴퓨터 ZX80, ZX81은 새줄 문자 코드가 0x76이었다.

과거 메인프레임 운영 체제는 텍스트 한 줄마다 레코드에 저장하는 방식을 사용했다. 레코드 시작 부분에 캐리지 제어 문자를 두어 줄바꿈이나 캐리지 리턴 여부를 조절했다.

일부 메인프레임 운영 체제는 고정된 줄 길이(주로 80자)로 한 줄을 저장했다. 외부에서 텍스트 파일을 받았을 때 한 줄이 80자보다 짧으면 공백 문자로 채우고, 너무 길면 잘라냈다. 이는 천공 카드 한 장마다 한 줄씩 기록하고 이 길이가 80자였던 방식을 모방한 것이다.

OpenVMS도 레코드 기반 파일 시스템을 사용한다. 텍스트 파일을 저장할 때 레코드마다 한 줄씩 저장한다. 대부분의 파일 형식에서 줄 구분 문자를 사용하지 않지만, 레코드 관리 서비스가 투명한 새줄 문자를 삽입할 수 있다.

캐리지 리턴(CR)과 라인 피드(LF)는 밀접하게 연관되어 있으며, 개별적으로 또는 함께 고려될 수 있다. 타자기와 프린터에서 새 줄을 만들려면 "아래"와 "가로" 두 축의 움직임이 필요하다. 기계 디자인은 이를 개별적으로 고려해야 하지만, 소프트웨어의 추상적 논리는 하나로 결합할 수 있다. 그래서 문자 인코딩에서 줄 바꿈이 CR과 LF를 하나로 결합한 것(보통 CR+LF 또는 CRLF)으로 정의될 수 있다.

일부 문자 집합은 별도의 줄 바꿈 문자 코드를 제공한다. 예를 들어, EBCDIC는 CR 및 LF 코드 외에도 NL 문자 코드를 제공한다. 유니코드는 ASCII CR 및 LF 제어 코드 외에도 "다음 줄"(NEL) 제어 코드와 "줄 구분 기호" 및 "단락 구분 기호" 마커에 대한 제어 코드를 제공한다. 유니코드에는 줄 바꿈, 캐리지 리턴 및 기타 C0 제어 코드를 시각적으로 나타내는 인쇄 가능한 문자가 제어 그림 블록에 포함되어 있다.

하나 또는 두 개의 제어 문자로 줄 바꿈을 표현하는 소프트웨어 응용 프로그램 및 운영 체제
운영 체제	문자 인코딩	약어	16진수 값	10진수 값	이스케이프 시퀀스
Multics POSIX 표준 지향 시스템: Unix 및 유닉스 계열 시스템 (Linux, macOS, *BSD, AIX, Xenix 등), QNX 4+ 기타: BeOS, Amiga, RISC OS, 기타^[5]	ASCII	LF	0A	10	\n
Windows, MS-DOS 호환, Atari TOS, DEC TOPS-10, RT-11, CP/M, MP/M, OS/2, Symbian OS, Palm OS, Amstrad CPC, 및 기타 초기 비유닉스 및 비IBM 운영 체제		CR LF	0D 0A	13 10	\r\n
Commodore 64, Commodore 128, Acorn BBC, ZX Spectrum, TRS-80, Apple II, Oberon, 클래식 Mac OS, HP Series 80, MIT Lisp 머신, 및 OS-9		CR	0D	13	\r
Acorn BBC^[6] 및 RISC OS 스풀 텍스트 출력^[7]		LF CR	0A 0D	10 13	\n\r
QNX 사전 POSIX 구현 (버전 < 4)		RS	1E	30	\036
Atari 8비트 컴퓨터	ATASCII	EOL	9B	155
IBM 메인프레임 시스템, z/OS (OS/390) 및 IBM i (OS/400) 포함	EBCDIC	NL	15	21	\025
ZX80 및 ZX81 (Sinclair Research Ltd의 가정용 컴퓨터)	ZX80/ZX81 고유 인코딩		76	118

EBCDIC 시스템(주로 IBM 메인프레임 시스템, z/OS (OS/390) 및 IBM i (OS/400) 포함)은 라인 피드 및 캐리지 리턴의 기능을 결합하는 문자로 NL (New Line, 15_(16진))을 사용한다.^[8] 해당 유니코드 문자(0x85)는 NEL (Next Line)이라고 한다. EBCDIC에는 CR 및 LF라는 제어 문자가 있지만, LF의 숫자 값(0x25)은 ASCII에서 사용되는 값(0x0A)과 다르다. 또한 일부 EBCDIC 변형은 NL을 사용하지만 해당 문자에 다른 숫자 코드를 할당한다. 그러나 해당 운영 체제는 레코드 지향 파일 시스템을 사용하며, 텍스트 파일을 줄당 하나의 레코드로 저장한다. 대부분의 파일 형식에서는 줄 종결자가 실제로 저장되지 않는다.
RSX-11 및 OpenVMS는 텍스트 파일을 줄당 하나의 레코드로 저장하는 레코드 기반 파일 시스템을 사용한다. 대부분 파일 형식에서는 줄 종결자가 실제로 저장되지 않지만, 레코드 관리 서비스는 응용 프로그램에서 검색할 때 각 줄에 종결자를 투명하게 추가할 수 있다. 레코드 자체에 동일한 줄 종결자 문자가 포함될 수 있다. RMS는 레코드를 저장할 뿐만 아니라 파일의 서로 다른 비트에 있는 레코드 구분 기호에 대한 메타데이터도 저장하여 문제를 더욱 복잡하게 만든다.
고정된 줄 길이는 일부 초기 메인프레임 컴퓨터 운영 체제에서 사용되었다. 이러한 시스템에서 암시적 줄 끝은 예를 들어 72 또는 80자마다 가정되었다. 줄 바꿈 문자는 저장되지 않았다. 외부에서 파일을 가져온 경우, 줄 길이가 짧은 줄은 공백으로 채워야 하고, 줄 길이가 긴 줄은 잘라야 했다. 이는 각 줄이 별도의 카드에 저장된 천공 카드의 사용을 모방했으며, 각 카드에는 일반적으로 80개의 열이 있었다. 이러한 시스템 중 다수는 캐리지 제어 문자를 다음 레코드의 시작 부분에 추가했다.

개행 문자(광의)는 다음 두 종류가 있으며, 시스템(소프트웨어)에 따라 한쪽 또는 양쪽이 사용된다.

캐리지 리턴(carriage return, CR, 복귀)
라인 피드(line feed, LF, 협의의 개행) 또는 뉴라인(newline, line break 또는 end-of-line, EOL)

이러한 용어는 타자기에서 유래되었다. 타자기에서는 인쇄 장치가 고정되어 있고, 종이가 상하좌우로 이동하여 문자 간격 조절 및 줄 바꿈이 이루어진다. 좌측 가로쓰기에서 "캐리지 리턴"은 종이를 고정하고 이동하는 장치(캐리지)를 원래 위치로 되돌리는 것(리턴, 즉 종이의 왼쪽 끝에 인쇄 장치가 오도록 하는 것)을 의미한다. "라인 피드"는 종이를 필요한 줄(라인)만큼 위로 올리는 것(피드, 즉 아래 줄에 인쇄 장치가 오도록 하는 것)을 의미한다.

컴퓨터에서는 같은 문자 코드를 사용하더라도 개행 코드가 다를 수 있으므로, 다른 시스템 간 데이터 교환 시 개행이 정확하게 반영되지 않을 수 있다.

대부분의 시스템에서, 줄 바꿈 코드는 하나 또는 연속된 두 개의 특수 문자로 표현된다.

ASCII 문자 코드 기반 시스템에서는, CR (캐리지 리턴, 0D_(16진)), LF (라인 피드, 0A_(16진)), 또는 CR+LF로 나타낸다.
LF: UNIX 및 유닉스 계열 시스템. 리눅스, 크롬 OS, AIX, 제닉스, macOS, BeOS, Amiga, RISC OS 등.
CR+LF: CP/M, MP/M, MS-DOS, OS/2, 마이크로소프트 윈도우.
CR: 코모도어 시스템, Apple II 제품군, Mac OS (버전 9까지), OS-9.
유니코드에서는, CR (U+000D)과 LF (U+000A) 외에, "다음 행" (next line)을 나타내는 NEL (U+0085), 행 구분 문자 (line separator)를 나타내는 LS (U+2028), 단락 구분 문자 (paragraph separator)를 나타내는 PS (U+2029)가 제공된다.
EBCDIC 시스템

: IBM의 메인프레임 시스템에서는 주로 NEL (Next Line, 15_(16진))을 줄 바꿈 코드로 사용한다. EBCDIC는 CR과 LF라고 불리는 제어 문자도 가지고 있지만, 이들은 ASCII에서의 CR과 LF와는 값이 다르다. 또한, NEL에 대해 다른 값을 할당한 EBCDIC의 변종도 존재한다. 고정 길이의 데이터 세트에서는, 일반적으로 줄 바꿈 코드 자체가 불필요하므로 사용되지 않는다.

OpenVMS는 레코드 기반 파일 시스템을 사용하며, 텍스트 파일의 각 행을 1개의 레코드로 저장한다. 저장할 때는 줄 바꿈 코드가 기록되지 않지만, 애플리케이션에서 읽어올 때 자동으로 행 종단 기호를 추가하는 기능이 있다.

인터넷상에서 사용되는, 텍스트로 정보를 주고받는 통신 프로토콜(HTTP, SMTP, FTP, IRC 등)은 프로토콜 레벨에서 CR+LF 코드를 사용할 것을 요구하고 있지만, 애플리케이션은 LF 코드에도 대응하는 것이 권장된다.

4. 프로그래밍 언어에서의 처리

프로그래밍 언어는 다양한 개행 문자 처리 방식을 제공한다.

이식성 있는 프로그램을 쉽게 만들기 위해, 프로그래밍 언어는 다양한 환경에서 사용되는 여러 유형의 새 줄 시퀀스를 처리하기 위한 추상화를 제공한다.

C 언어는 `\n` (줄 바꿈) 및 `\r` (캐리지 리턴) 이스케이프 시퀀스를 제공하며, 이들은 각각의 환경에 맞는 특정 숫자 코드로 변환된다. 예를 들어, 유닉스와 윈도우에서는 각각 `0A`_(16진)와 `0D`_(16진)으로 변환된다. 그러나 텍스트 모드에서 파일을 읽고 쓸 때는 시스템의 기본 줄 바꿈 코드로 자동 변환이 일어난다.

Java 역시 `\n`과 `\r` 이스케이프 시퀀스를 제공하며, 이들은 각각 16비트 숫자 `000A`_(16진)와 `000D`_(16진)로 변환된다. Java에서는 C와 달리 입출력 시 자동 변환이 일어나지 않지만, 줄 바꿈을 위한 특수 표기("%n")나 기본 줄 구분 기호를 얻는 메서드를 제공한다.

파이썬은 "범용 새 줄 지원"을 통해 다양한 개행 문자를 처리한다.

Perl^[20], PHP^[21], C# 등 다른 언어들도 새 줄 처리를 위한 이스케이프 시퀀스, 상수, 메서드 등을 제공한다.

4. 1. C/C++

C 언어는 `\n` (줄 바꿈) 및 `\r` (캐리지 리턴) 이스케이프 시퀀스를 제공한다. 그러나 이것들이 ASCII 제어 문자와 동일할 필요는 없다. C 표준은 두 가지 특성만 보장한다.

# 이러한 각 이스케이프 시퀀스는 하나의 `char` 값에 저장할 수 있는 고유한 구현 정의 번호에 매핑된다.

# ''텍스트 모드''에서 파일, 장치 노드 또는 소켓/fifo에 쓸 때, `\n`은 시스템에서 사용되는 기본 새 줄 시퀀스로 투명하게 변환되며, 이는 한 문자보다 길 수 있다. 텍스트 모드로 읽을 때 기본 새 줄 시퀀스는 다시 `\n`으로 변환된다. ''이진 모드''에서는 변환이 수행되지 않으며, `\n`에 의해 생성된 내부 표현이 직접 출력된다.

C가 시작된 유닉스 운영 체제 플랫폼에서 기본 새 줄 시퀀스는 ASCII LF (0x0A)이므로 `\n`은 단순히 해당 값으로 정의되었다. 내부 및 외부 표현이 동일하므로 텍스트 모드에서 수행되는 변환은 무작업이며, 유닉스에는 텍스트 모드 또는 이진 모드에 대한 개념이 없다. 이로 인해 유닉스 시스템에서 소프트웨어를 개발한 많은 프로그래머가 이러한 구분을 완전히 무시하여 다른 플랫폼으로 이식할 수 없는 코드가 생성되었다.

C 표준 라이브러리 함수 `fgets()`는 유닉스 새 줄 규칙으로 쓰여지지 않은 파일이 잘못 읽히기 때문에 이진 모드에서는 사용하지 않는 것이 좋다. 또한, 텍스트 모드에서는 시스템의 기본 새 줄 시퀀스(예: 유닉스 시스템에서 생성되어 윈도우 시스템으로 복사된 파일)로 쓰여지지 않은 파일도 잘못 읽힌다.

또 다른 일반적인 문제는 줄의 끝에 ASCII CR+LF를 사용하도록 규정하는 인터넷 프로토콜을 사용할 때 `\n`을 사용하는 것이다. `\n`을 텍스트 모드 스트림에 쓰는 것은 윈도우 시스템에서는 제대로 작동하지만 유닉스에서는 LF만 생성하고, 더 이국적인 시스템에서는 완전히 다른 것을 생성한다. 이진 모드에서 `\r\n`을 사용하는 것이 약간 더 좋다.

C++는 C와 동일한 `\n` 해석을 제공한다. C++에는 조작자 `std::endl`을 사용하여 새 줄을 출력할 수 있는 대체 입출력 (I/O) 모델이 있다 (스트림 버퍼를 플러시함).

여러 운영 체제를 지원하는 프로그램을 작성하기 위해 프로그래밍 언어는 서로 다른 줄 바꿈 코드를 처리하기 위한 어느 정도의 추상성을 제공한다.

C 언어에서는 `'\n'`(줄 바꿈)과 `'\r'`(캐리지 리턴) 두 개의 이스케이프 시퀀스를 제공한다. 언어 처리기는 이러한 이스케이프 시퀀스를 각각 다른 환경 종속적인 `char` 형으로 들어갈 수 있는 범위의 바이트 열로 변환한다. 예를 들어 UNIX와 Windows의 일반적인 처리기에서는 각각 0x0A와 0x0D이다.

단, I/O용 라이브러리 내에서 `'\n'`에 해당하는 수치 (위의 예에서는 0x0A)가 특수한 값으로 처리되는 시스템도 있다. 이러한 출력 함수는 텍스트 모드로 열린 파일에 데이터를 출력할 때, `'\n'` 부분이 시스템에서 사용되는 줄 바꿈 코드 열로 변환된 문자열이 파일에 출력된다. 예를 들어, UNIX에서는 줄 바꿈 코드 열이 "0x0A"이고, Windows에서는 "0x0D 0x0A", Macintosh에서는 "0x0D"이다. 또한 입력 함수 `fgets`, `fread`, `read`는 텍스트 모드로 열린 파일에서 데이터를 읽을 때 파일 내에 시스템 종속적인 줄 바꿈 코드 열이 있으면 해당 부분을 `'\n'`에 해당하는 수치로 변환한 것을 변수에 저장한다. 파일이 바이너리 모드로 열려 있는 경우에는 어떤 입출력 함수도 수치 변환을 하지 않고 그대로의 값으로 읽고 쓴다.

이러한 함수는 "0x0D 0x0A"의 사용을 요구하는 통신 프로토콜을 사용하여 텍스트를 주고받을 때 문제가 된다. 그러한 스트림에 `printf` 함수 등을 사용하여 `'\n'`을 출력하면, Windows 시스템에서는 예상대로 "0x0D 0x0A"가 전송되지만, UNIX에서는 "0x0A"만 전송되므로 문제가 된다. 해결책으로 바이너리 모드를 사용하여 목적하는 수치 (0x0D 0x0A)를 직접 보내면 어떤 경우에도 제대로 작동한다.

4. 2. Java

Java에서는 줄 바꿈을 위해 '\n' (라인 피드, LF)와 '\r' (캐리지 리턴, CR) 이스케이프 시퀀스를 사용한다. 이들은 각각 와 값을 나타내도록 보장된다.^[22]

Java 클래스 라이브러리의 입출력(I/O) 메서드는 입출력 시 이들을 플랫폼 종속적인 줄 바꿈 시퀀스로 자동 변환하지 않는다. 대신, 기본 줄 바꿈 시퀀스를 자동으로 추가하는 전체 줄 쓰기 함수와 , , 또는 중 하나를 줄 종결자로 허용하는 줄 읽기 함수를 제공한다. 기본 줄 구분 기호는 `System.lineSeparator()` 메서드를 사용하여 검색할 수 있다.^[23]

예시:

```java

String eol = System.lineSeparator();

String lineColor = "Color: Red" + eol;

```

자주 사용되는 `java.io.PrintStream` 클래스의 `print`, `println`, `printf` 메서드는 C 언어의 `printf` 함수와 달리, 이러한 수치를 특별 취급하여 환경 종속적인 줄 바꿈 코드로 변환하지 않는다. 단, `printf` 메서드에서 사용되는 서식 문자열 내에서는 "줄 바꿈"을 표현하기 위한 특수한 표기인 "%n"을 사용할 수 있다. `printf` 메서드는 이 부분을 실행 환경 종속적인 줄 바꿈 코드로 대체한 문자열을 출력한다. 또한, 어떤 메서드에서도 출력되는 바이트 수, 바이트 순서에 대해서는 설정된 문자 인코딩에 의존한다.

4. 3. Python

파이썬은 파일을 읽거나, 모듈을 가져오거나, 파일을 실행할 때 "범용 새줄 지원"을 허용하여 다양한 개행 문자를 처리한다.^[23]

4. 4. 기타 언어

C, C++, Perl^[20], Haskell과 같은 많은 프로그래밍 언어는 `\n`(줄 바꿈)과 `\r`(캐리지 리턴) 이스케이프 시퀀스를 제공한다. C 표준은 이들이 하나의 `char` 값에 저장될 수 있는 고유한 번호로 매핑되고, 텍스트 모드에서 파일 등에 쓸 때 시스템의 기본 새 줄 시퀀스로 변환되도록 보장한다.

C가 시작된 유닉스 플랫폼에서는 `\n`이 ASCII `LF`(0x0A)로 정의되었다. 유닉스는 텍스트/이진 모드 구분이 없어 변환이 필요 없었지만, 이로 인해 다른 플랫폼으로 이식할 수 없는 코드가 만들어지기도 했다.

C 표준 라이브러리 함수 `fgets()`는 유닉스 새 줄 규칙으로 작성되지 않은 파일을 잘못 읽을 수 있어 이진 모드에서 사용하지 않는 것이 좋다. 텍스트 모드에서는 시스템의 기본 새 줄 시퀀스로 작성되지 않은 파일도 잘못 읽힐 수 있다.

인터넷 프로토콜에서 `\n`을 사용하면 윈도우에서는 작동하지만 유닉스에서는 `LF`만 생성하고, 다른 시스템에서는 다른 결과를 낼 수 있다. 이진 모드에서 `\r\n`을 사용하는 것이 더 낫다.

C++는 `std::endl` 조작자를 사용하여 새 줄을 출력할 수 있다. Java, PHP^[21], Python^[22]은 `\r\n` 시퀀스를 제공하며, 이는 각각 U+000D 및 U+000A 값을 나타낸다. Java는 입출력 시 플랫폼 종속적인 새 줄 시퀀스로 자동 변환하지 않으며, `System.lineSeparator()` 메서드로 기본 줄 구분 기호를 검색할 수 있다.

예시:

```java

String eol = System.lineSeparator();

String lineColor = "Color: Red" + eol;

```

파이썬은 파일을 읽거나 실행할 때 "범용 새 줄 지원"을 허용한다.^[23]

일부 언어는 새 줄을 위한 특수 변수, 상수, 서브루틴을 제공한다. PHP에서는 PHP_EOL 상수를 사용해야 한다.^[24]

C# 예시:

```csharp

string eol = Environment.NewLine;

string lineColor = "Color: Red" + eol;

string eol2 = "\n";

string lineColor2 = "Color: Blue" + eol2;

5. 호환성 문제 및 해결 방안

서로 다른 운영 체제에서 사용하는 개행 문자(Newline)가 달라 텍스트 파일 호환성에 문제가 발생할 수 있다.

MS-DOS와 마이크로소프트 윈도우는 캐리지 리턴(CR)과 라인 피드(LF)를 모두 사용 (CRLF)하는 반면, 유닉스 계열 시스템은 LF만 사용하고, 클래식 Mac OS는 CR만 사용한다. 이러한 차이로 인해 한 운영 체제에서 작성된 텍스트 파일이 다른 운영 체제에서 제대로 표시되지 않을 수 있다. 예를 들어, 유닉스에서 작성된 파일은 윈도우에서 모든 내용이 한 줄로 표시될 수 있고, 윈도우에서 작성된 파일은 유닉스에서 각 줄 끝에 `^M`과 같은 특수 문자가 추가로 표시될 수 있다.

이러한 문제를 해결하기 위해 다음과 같은 방법을 사용할 수 있다.

텍스트 편집기 사용: 대부분의 최신 텍스트 편집기는 서로 다른 개행 문자 형식을 인식하고 변환할 수 있는 기능을 제공한다. 예를 들어, Vim에서는 `:set fileformat=dos` 명령을 사용하여 파일을 윈도우 형식으로 저장할 수 있다.
특수 목적 프로그램 사용: `unix2dos`, `dos2unix` 등의 유틸리티는 개행 문자를 특정 운영 체제 형식으로 변환해준다.
명령 줄 도구 사용: 유닉스 계열 시스템의 `tr` 명령어를 사용하여 개행 문자를 변경할 수 있다. 예를 들어, `tr -d '\r'` 명령어는 윈도우 형식 파일에서 CR 문자를 제거하여 유닉스 형식으로 변환한다.
프로그래밍 언어의 추상화 활용: C 언어, Java, Python 등 대부분의 프로그래밍 언어는 개행 문자를 처리하기 위한 추상적인 방법을 제공한다. 예를 들어, C 언어의 `\n`은 시스템에 맞는 개행 문자로 자동 변환된다.

파일 전송 프로토콜(FTP)을 사용할 때는 ASCII 모드로 전송하면 개행 문자가 자동으로 변환되지만, 바이너리 파일은 손상될 수 있으므로 주의해야 한다.

인터넷 기술 특별 위원회(IETF)에서 발표한 프로토콜은 일반적으로 ASCII CRLF 시퀀스를 사용하지만, 일부 응용 프로그램은 LF만 사용하기도 하여 호환성 문제가 발생할 수 있다.

5. 1. 문제점

유닉스 계열 또는 클래식 Mac OS에서 흔히 사용되는 프로그램으로 생성된 파일의 텍스트는 대부분의 MS-DOS 및 마이크로소프트 윈도우에서 흔히 사용되는 프로그램에서 한 줄로 표시된다. 이 프로그램들은 단일 라인 피드(LF) 또는 단일 캐리지 리턴(CR)을 줄 바꿈으로 표시하지 않기 때문이다.^[3]^[4]

반대로, 유닉스 계열 시스템에서 윈도우 컴퓨터에서 온 파일을 볼 때, 추가 CR은 두 번째 줄 바꿈, `^M`, 또는 각 줄의 끝에 ``로 표시될 수 있다.

더욱이, 텍스트 편집기가 아닌 다른 프로그램은 다른 줄 바꿈 규칙을 사용하여 인코딩된 파일(예: 일부 구성 파일)을 유효한 파일로 허용하지 않을 수 있다.

일부 프로그램은 다른 줄 바꿈을 제대로 처리하는 반면 다른 프로그램은 그렇지 않기 때문에 이 문제는 발견하기 어려울 수 있다. 예를 들어, 컴파일러는 콘솔이나 편집기에서 소스 파일이 올바르게 표시될 때에도 모호한 구문 오류로 실패할 수 있다. 최신 텍스트 편집기는 일반적으로 모든 종류의 CR+LF 줄 바꿈을 인식하고 사용자가 서로 다른 표준 간에 변환할 수 있도록 한다. 웹 브라우저도 일반적으로 서로 다른 유형의 줄 바꿈을 사용하는 텍스트 파일 및 웹 사이트를 표시할 수 있다.

프로그램이 다른 줄 바꿈 규칙을 지원하더라도 이러한 기능은 종종 충분히 라벨이 지정되거나 설명되거나 문서화되지 않는다. 일반적으로 사용자가 선택 사항이 줄 바꿈을 재해석하거나, 임시로 변환하거나, 영구적으로 변환할지 여부를 표시하지 않고 서로 다른 줄 바꿈 규칙을 열거하는 메뉴 또는 콤보 상자가 표시된다. 일부 프로그램은 열기, 복사, 붙여넣기 또는 저장 시 암시적으로 변환하며, 이는 종종 일관성이 없다.

대부분의 텍스트 인터넷 프로토콜 (HTTP, SMTP, FTP, IRC 등을 포함)은 프로토콜 수준에서 ASCII CR+LF (`\r\n`, )의 사용을 의무화하지만, 관대한 응용 프로그램이 독립형 LF (`\n`, )도 인식하도록 권장한다. 규정된 표준에도 불구하고, 많은 응용 프로그램은 캐리지 리턴 이스케이프와 줄 바꿈 이스케이프 시퀀스 `\r\n` (CR+LF)의 올바른 조합 대신 C 줄 바꿈 이스케이프 시퀀스 `\n` (LF)을 잘못 사용한다. 이 잘못된 이스케이프 시퀀스의 우발적인 사용은 관대한 해석 대신 표준의 더 엄격한 해석을 준수하는 시스템과 통신하려고 할 때 문제를 야기한다. 그러한 관대하지 않은 시스템 중 하나는 필요한 CR+LF 대신 순수 LF를 보내는 시스템으로부터 메시지를 적극적으로 거부하는 qmail 메일 전송 에이전트이다.^[25]

이메일에 대한 표준 인터넷 메시지 형식^[26]은 "CR 및 LF는 CRLF로만 함께 발생해야 하며, 본문에서 독립적으로 나타나면 안 됩니다."라고 명시한다. SMTP 구현 간의 순수 LF 및/또는 순수 CR 문자를 처리하는 방식의 차이로 인해 "SMTP 스머글링"이라고 하는 SMTP 스푸핑 공격이 발생했다.^[27]

파일 전송 프로토콜은 전송이 "ASCII 모드"로 수행될 때 다른 줄 바꿈 표현을 가진 시스템 간에 전송되는 파일에서 줄 바꿈을 자동으로 변환할 수 있다. 그러나 이 모드에서 바이너리 파일을 전송하는 것은 일반적으로 재앙적인 결과를 낳는다. 이 컨텍스트에서 줄 종결 의미론을 갖지 않고 단지 일반 바이트 시퀀스의 일부인 줄 바꿈 바이트 시퀀스가 다른 시스템이 사용하는 줄 바꿈 표현으로 변환되어 파일이 효과적으로 손상된다. FTP 클라이언트는 종종 일부 휴리스틱 (예: 파일 확장자 검사)을 사용하여 바이너리 모드 또는 ASCII 모드를 자동으로 선택하지만, 결국 사용자가 파일을 올바른 모드로 전송해야 한다. 올바른 모드에 대한 의문이 있는 경우 바이너리 모드를 사용해야 한다. 그러면 FTP에 의해 파일이 변경되지 않지만 잘못 표시될 수 있다.^[28]

5. 2. 해결 방안

텍스트 편집기나 변환 도구를 사용하여 개행 문자를 변환할 수 있다. 예를 들어, 텍스트 편집기 Vim은 파일을 Windows 메모장 텍스트 편집기와 호환되도록 만들 수 있다.^[29] Vim 내에서 다음과 같이 명령을 실행한다.

:set fileformat=dos

:wq

Vim과 같은 텍스트 편집기는 더 큰 파일의 변환이나 여러 파일의 일괄 변환에는 부적합할 수 있다.^[29] 더 큰 파일의 경우에는 (Windows NT에서) 다음 명령이 자주 사용된다.^[29]

D:\>TYPE unix_file | FIND /V "" > dos_file

unix2dos와 dos2unix, mac2unix 및 unix2mac, mac2dos 및 dos2mac, flip과 같은 특수 목적 프로그램을 사용하여 파일을 서로 다른 줄 바꿈 규칙 간에 변환할 수 있다.^[29]

유닉스 계열 시스템에서는 `tr` 명령을 사용하여 단일 문자에 대한 임의의 대체 작업을 수행할 수 있다. 예를 들어, DOS/Windows 텍스트 파일은 모든 ASCII `` 문자를 제거하여 유닉스 형식으로 변환할 수 있다.^[29]

$ tr -d '\r' < ''inputfile'' > ''outputfile''

텍스트에 `` 줄 바꿈만 있는 경우, 모든 `` 줄 바꿈을 ``로 변환하여 변환할 수 있다.^[29]

$ tr '\r' '\n' < ''inputfile'' > ''outputfile''

동일한 작업은 awk, sed 또는 Perl 인터프리터가 있는 플랫폼의 경우 Perl로 수행할 수 있다.^[29]

$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile # UNIX to DOS (adding CRs on Linux and BSD based OS that haven't GNU extensions)

$ awk '{gsub("\r",""); print;}' inputfile > outputfile # DOS to UNIX (removing CRs on Linux and BSD based OS that haven't GNU extensions)

$ sed -e 's/$/\r/' inputfile > outputfile # UNIX to DOS (adding CRs on Linux based OS that use GNU extensions)

$ sed -e 's/\r$//' inputfile > outputfile # DOS to UNIX (removing CRs on Linux based OS that use GNU extensions)

$ perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile # Convert to DOS

$ perl -pe 's/\r?\n|\r/\n/g' inputfile > outputfile # Convert to UNIX

$ perl -pe 's/\r?\n|\r/\r/g' inputfile > outputfile # Convert to old Mac

`file` 명령은 줄 끝 유형을 식별할 수 있다.^[29]

$ file myfile.txt

myfile.txt: ASCII English text, with CRLF line terminators

유닉스 egrep (확장 grep) 명령을 사용하여 유닉스 또는 DOS 파일의 파일 이름을 인쇄할 수 있다 (유닉스 및 DOS 스타일 파일만 가정하고 클래식 Mac OS 스타일 파일은 없음).^[29]

$ egrep -L '\r\n' myfile.txt # show UNIX style file (LF terminated)

$ egrep -l '\r\n' myfile.txt # show DOS style file (CRLF terminated)

다른 도구를 사용하면 EOL 문자를 시각화할 수 있다.^[29]

$ od -a myfile.txt

$ cat -e myfile.txt

$ cat -v myfile.txt

$ hexdump -c myfile.txt

프로그래밍 언어는 다양한 환경에서 사용되는 여러 유형의 새줄 시퀀스를 처리하기 위한 추상화를 제공한다. C 언어는 `\n`(줄 바꿈) 및 `\r`(캐리지 리턴) 이스케이프 시퀀스를 제공하지만, 이들은 ASCII `` 및 `` 제어 문자와 동일할 필요는 없다.^[23]

C 표준 라이브러리 함수 `fgets()`는 유닉스 새줄 규칙으로 쓰여지지 않은 파일이 잘못 읽힐 수 있으므로 이진 모드에서는 사용하지 않는 것이 좋다. 텍스트 모드에서는 시스템의 기본 새줄 시퀀스로 쓰여지지 않은 파일도 잘못 읽힐 수 있다.^[23]

C++, Perl^[20] 및 Haskell과 같은 많은 언어는 C와 동일한 `\n` 해석을 제공한다. C++에는 조작자 `std::endl`을 사용하여 새줄을 출력할 수 있는 대체 입출력 (I/O) 모델이 있다.^[23]

Java, PHP^[21] 및 Python^[22]은 `\r\n` 시퀀스(ASCII ``용)를 제공하며, 각각 `` 및 `` 값을 나타내는 것이 보장된다.

자바 클래스 라이브러리 입출력 (I/O) 메서드는 입출력 시 이러한 것들을 플랫폼 종속적인 새줄 시퀀스로 투명하게 변환하지 않는다. 대신, 기본 새줄 시퀀스를 자동으로 추가하는 전체 줄을 쓰기 위한 함수와 ``, ``, 또는 `` 중 하나를 줄 종결자로 허용하는 줄을 읽기 위한 함수를 제공한다. `System.lineSeparator()` 메서드를 사용하여 기본 줄 구분 기호를 검색할 수 있다.^[23]

파이썬은 파일을 읽기 위해 열거나, 모듈을 가져오거나, 파일을 실행할 때 "범용 새줄 지원"을 허용한다.^[23]

일부 언어는 프로그램 실행 중에 새줄을 용이하게 하기 위해 특수 변수, 상수, 및 서브루틴을 만들었다. PHP에서는 이식성 문제를 피하기 위해 PHP_EOL 상수를 사용하여 새줄 시퀀스를 발행해야 한다.^[24]

C#의 예:

string eol = Environment.NewLine;

string lineColor = "Color: Red" + eol;

string eol2 = "\n";

string lineColor2 = "Color: Blue" + eol2;

많은 통신 프로토콜은 새 줄 표기법을 가지고 있다. 인터넷 기술 특별 위원회(IETF)에서 발표한 프로토콜은 일반적으로 ASCII CRLF 시퀀스를 사용하지만, 관대한 응용 프로그램이 독립형 ``도 인식하도록 권장한다.^[25]

6. 한국 IT 환경과 개행 문자

새줄 문자는 한국의 IT 환경에서 여러 문제를 야기한다. 특히, 마이크로소프트 윈도우와 다른 운영체제(리눅스, macOS 등) 간의 개행 문자 처리 방식 차이로 인해 문서 호환성 문제가 발생한다.

윈도우는 새줄을 CR(Carriage Return, \r)과 LF(Line Feed, \n)의 조합인 CRLF(\r\n)로 표현하는 반면, 리눅스와 macOS는 LF(\n)만을 사용한다. 이로 인해 윈도우에서 작성된 텍스트 파일을 리눅스나 macOS에서 열면 줄바꿈이 제대로 표시되지 않거나, 반대로 리눅스나 macOS에서 작성된 파일이 윈도우에서 깨져 보일 수 있다.

이러한 문제는 웹 브라우저에서도 나타난다. HTML이나 CSS 등 웹 표준은 LF(\n)를 개행 문자로 정의하고 있지만, 일부 구형 윈도우 환경에서는 CRLF(\r\n)를 사용해야 하는 경우가 있어 웹 개발 시 주의가 필요하다.

과거 김대중 정부와 노무현 정부는 윈도우 중심의 IT 환경에서 벗어나 리눅스 등 다양한 운영체제를 지원하는 정책을 추진하여, 특정 운영체제에 종속되지 않는 개방적인 IT 환경을 조성하는 데 기여했다.

참조

_[1] 웹사이트 What is a Newline? https://www.computer[...] 2021-05-10
_[2] 서적 Vi Improved - Vim http://ftp.vim.org/p[...] Sams Publishing 2023-01-04
_[3] 뉴스 Windows Notepad finally understands everyone else's end of line characters https://www.zdnet.co[...] ZDNet 2023-01-04
_[4] 웹사이트 Introducing extended line endings support in Notepad https://devblogs.mic[...] 2023-01-04
_[5] 웹사이트 ASCII chart https://www.bluesock[...]
_[6] 서적 The Advanced User Guide for the BBC Microcomputer http://stardot.org.u[...] Cambridge Microcomputer Centre 2019-01-30
_[7] 웹사이트 Character Output http://www.riscos.co[...] 3QD Developments Ltd 2018-07-18
_[8] 문서 IBM System/360 Reference Data Card IBM Data Processing Division
_[9] 웹사이트 UAX #14: Unicode Line Breaking Algorithm https://www.unicode.[...] The Unicode Consortium 2013-09-20
_[10] 웹사이트 C1 Control Character Set of ISO 6429 https://www.itscj-ip[...] IPSJ 2022-03-03
_[11] 보고서 Control Functions for Coded Character Sets http://www.ecma-inte[...] ECMA International 1991-06
_[12] 보고서 Character Code Structure and Extension Techniques http://www.ecma-inte[...] ECMA International 1994-12
_[13] 웹사이트 ECMAScript 2019 Language Specification https://www.ecma-int[...] ECMA International 2019-06
_[14] 웹사이트 ECMAScript 2019 Language Specification https://www.ecma-int[...] ECMA International 2019-06
_[15] IETF The JavaScript Object Notation (JSON) Data Interchange Format 2014-03
_[16] 웹사이트 Subsume JSON (a.k.a. JSON ⊂ ECMAScript) https://github.com/t[...] 2018-05-22
_[17] 웹사이트 ECMAScript 2019 Language Specification https://www.ecma-int[...] ECMA International 2019-06
_[18] 웹사이트 ECMAScript 2018 Language Specification https://www.ecma-int[...] ECMA International 2018-06
_[19] 웹사이트 5.4. Line Break Characters https://yaml.org/spe[...] 2021-10-01
_[20] 웹사이트 binmode https://perldoc.perl[...] Perl 5 Porters
_[21] 웹사이트 PHP: Strings - Manual https://www.php.net/[...] The PHP Group
_[22] 웹사이트 2. Lexical analysis https://docs.python.[...] The Python Foundation
_[23] 웹사이트 What's new in Python 2.3 https://www.python.o[...] Python Software Foundation
_[24] 웹사이트 PHP: Predefined Constants - Manual https://www.php.net/[...] The PHP Group
_[25] 웹사이트 Bare LFs in SMTP https://cr.yp.to/doc[...]
_[26] IETF Internet Message Format https://tools.ietf.o[...] 2001-04
_[27] 웹사이트 SMTP Smuggling - Spoofing E-Mails Worldwide https://sec-consult.[...] 2023-12-18
_[28] 웹사이트 File Transfer https://www.cs.odu.e[...] Old Dominion University 2015-01-19
_[29] 웹사이트 ASCII text converstion between UNIX, Macintosh, MS-DOS http://ccrma-www.sta[...] Center for Computer Research in Music and Acoustics
_[30] 웹사이트 C1 Controls and Latin-1 Supplement https://www.unicode.[...] 2016-02-13

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com